home *** CD-ROM | disk | FTP | other *** search
/ Info-Mac 4 / Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso / Periodicals / CSMP / C.S.M.P. Digest, Issue 3.027 < prev    next >
Internet Message Format  |  1994-06-09  |  81KB

  1. From: pottier@clipper.ens.fr (Francois Pottier)
  2. Subject: csmp-digest-v3-027
  3. Date: Sun, 15 May 94 21:57:08 MET DST
  4.  
  5. C.S.M.P. Digest             Sun, 15 May 94       Volume 3 : Issue 27
  6.  
  7. Today's Topics:
  8.  
  9.         Determining if user has a CD ROM drive
  10.         Lex and Yacc for Mac Programmers
  11.         PowerMac FP performance - interesting results????
  12.         Saving the floating Point Registers
  13.         The NewWindow case
  14.         Truetype font format specification: No longer available from Apple ?!
  15.  
  16.  
  17.  
  18. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  19. (pottier@clipper.ens.fr).
  20.  
  21. The digest is a collection of article threads from the internet newsgroup
  22. comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
  23. regularly and want an archive of the discussions.  If you don't know what a
  24. newsgroup is, you probably don't have access to it.  Ask your systems
  25. administrator(s) for details.  If you don't have access to news, you may
  26. still be able to post messages to the group by using a mail server like
  27. anon.penet.fi (mail help@anon.penet.fi for more information).
  28.  
  29. Each issue of the digest contains one or more sets of articles (called
  30. threads), with each set corresponding to a 'discussion' of a particular
  31. subject.  The articles are not edited; all articles included in this digest
  32. are in their original posted form (as received by our news server at
  33. nef.ens.fr).  Article threads are not added to the digest until the last
  34. article added to the thread is at least two weeks old (this is to ensure that
  35. the thread is dead before adding it to the digest).  Article threads that
  36. consist of only one message are generally not included in the digest.
  37.  
  38. The digest is officially distributed by two means, by email and ftp.
  39.  
  40. If you want to receive the digest by mail, send email to listserv@ens.fr
  41. with no subject and one of the following commands as body:
  42.     help                        Sends you a summary of commands
  43.     subscribe csmp-digest Your Name    Adds you to the mailing list
  44.     signoff csmp-digest            Removes you from the list
  45. Once you have subscribed, you will automatically receive each new
  46. issue as it is created.
  47.  
  48. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
  49. Questions related to the ftp site should be directed to
  50. scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
  51. digest are available there.
  52.  
  53. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.
  54.  
  55.  
  56. -------------------------------------------------------
  57.  
  58. >From mkelly@cs.uoregon.edu (Michael A. Kelly)
  59. Subject: Determining if user has a CD ROM drive
  60. Date: 25 Apr 1994 15:18:08 -0700
  61. Organization: High Risk Ventures
  62.  
  63.  
  64. Hey,
  65.  
  66. Is there any way to determine (through software) if a given machine has a
  67. CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  68. larger than 500MB (and wouldn't that only show up if there's a CD mounted)?
  69. Is there any other way?
  70.  
  71. Thanks,
  72.  
  73. Mike.
  74. -- 
  75. _____________________________________________________________________________
  76. Michael A. Kelly                                                President/CEO
  77. mkelly@cs.uoregon.edu                                      High Risk Ventures
  78. _____________________________________________________________________________
  79.  
  80. +++++++++++++++++++++++++++
  81.  
  82. >From mxmora@unix.sri.com (Matt Mora)
  83. Date: 25 Apr 1994 16:55:17 -0700
  84. Organization: SRI International, Menlo Park, CA
  85.  
  86. In article <2phfj0$95h@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  87. >
  88. >Hey,
  89. >
  90. >Is there any way to determine (through software) if a given machine has a
  91. >CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  92. >larger than 500MB (and wouldn't that only show up if there's a CD mounted)?
  93. >Is there any other way?
  94.  
  95.  
  96. Sure,
  97.  
  98. Here you go:
  99.  
  100. //------------------------------------------------------------
  101.   pascal  OSErr OpenCD(Byte CDDrive, short *ioRefNum) {
  102. //------------------------------------------------------------
  103.  
  104.   auto  OSErr     osErr;
  105.   auto  short     ioRefNumTemp,
  106.                   CDDriveCount,
  107.                   SCSIID;
  108.   auto  WhoIsThereRec *pb;
  109.  
  110.   pb = (WhoIsThereRec *) NewPtrClear(sizeof (*pb));
  111.   osErr = MemError();
  112.   if (0 != pb && noErr == osErr) {
  113.     osErr = OpenDriver("\p.AppleCD", &ioRefNumTemp);
  114.     if (noErr == osErr) {
  115.       (*pb).ioRefNum    = ioRefNumTemp;
  116.       (*pb).csCode    = csWhoIsThere;
  117.       osErr = PBStatus((ParmBlkPtr)pb, false);
  118.       if (noErr == osErr) {
  119.         CDDriveCount = 0;
  120.         for (SCSIID = 0; SCSIID < 7; ++SCSIID) {
  121.           if (BitTst(&(*pb).csParam.SCSIMask, 7 - SCSIID)) {
  122.             ++CDDriveCount;
  123.             if (CDDrive == CDDriveCount) {
  124.               *ioRefNum = -(32 + SCSIID) - 1;
  125.               DisposPtr((Ptr) pb);
  126.               return noErr;
  127.             }
  128.           }
  129.         }
  130.         osErr = paramErr;
  131.       }
  132.     }
  133.     DisposPtr((Ptr) pb);
  134.   }
  135.   return osErr;
  136. }
  137.  
  138.  
  139. I didn't write it it came from:
  140.  
  141. // imWare
  142. // Wednesday, February 14, 1990
  143. // James Beninghaus
  144.  
  145.  
  146. Xavier
  147.  
  148.  
  149. -- 
  150. ___________________________________________________________
  151. Matthew Xavier Mora                       Matt_Mora@sri.com
  152. SRI International                       mxmora@unix.sri.com
  153. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  154.  
  155. +++++++++++++++++++++++++++
  156.  
  157. >From mclow@csusm.edu (Marshall Clow)
  158. Date: 26 Apr 1994 00:36:17 GMT
  159. Organization: (none)
  160.  
  161. Matt Mora (mxmora@unix.sri.com) wrote:
  162. >In article <2phfj0$95h@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu
  163. > (Michael A. Kelly) writes:
  164. >>
  165. >>Hey,
  166. >>
  167. >>Is there any way to determine (through software) if a given machine has a
  168. >>CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  169. >>larger than 500MB (and wouldn't that only show up if there's a CD mounted)?
  170. >>Is there any other way?
  171.  
  172.  
  173. >Sure,
  174.  
  175. >Here you go:
  176.  
  177. [ code deleted ]
  178.  
  179. Matt,
  180.     Pardon me if I missed something, but the code that you posted
  181. only works if the Apple CD-ROM drivers are installed. What if the CD-ROM
  182. that the user has uses it's own, custom driver?
  183.  
  184. Perhaps if the original poster could provide some more information
  185. about what he was trying to accomplish, someone could suggest a solution.
  186.  
  187. -- Marshall
  188.  
  189. Marshall Clow
  190. I are an Engineer!
  191. Aladdin Systems
  192. mclow@san_marcos.csusm.edu
  193.  
  194.  
  195. +++++++++++++++++++++++++++
  196.  
  197. >From mkelly@cs.uoregon.edu (Michael A. Kelly)
  198. Date: 26 Apr 1994 00:08:21 -0700
  199. Organization: High Risk Ventures
  200.  
  201. In article <2phnm1$dqm@coyote.csusm.edu>,
  202. Marshall Clow <mclow@csusm.edu> wrote:
  203. >    Pardon me if I missed something, but the code that you posted
  204. >only works if the Apple CD-ROM drivers are installed. What if the CD-ROM
  205. >that the user has uses it's own, custom driver?
  206. >
  207. >Perhaps if the original poster could provide some more information
  208. >about what he was trying to accomplish, someone could suggest a solution.
  209.  
  210. I simply want to know if there is a CD ROM drive attached to the machine.
  211. I am not going to do anything with that information, besides take note of
  212. it.  It will become part of a 'system code' that the user can give to a
  213. tech support person when there is trouble - rather than the tech support
  214. person having to ask the user for each tidbit of information, they just
  215. ask for this code, which immediately gives them all the basic information
  216. they need about the user's machine.
  217.  
  218. Of course, whether or not the user has a CD ROM drive is pretty unimportant
  219. for tech support (if it was important it would probably be given).  This
  220. system code is also used to give us some statistics about the number of
  221. CD ROM drives in our customer base.
  222.  
  223. All of this is irrelevant to the question at hand, though.
  224.  
  225. Mike.
  226. -- 
  227. _____________________________________________________________________________
  228. Michael A. Kelly                                                President/CEO
  229. mkelly@cs.uoregon.edu                                      High Risk Ventures
  230. _____________________________________________________________________________
  231.  
  232. +++++++++++++++++++++++++++
  233.  
  234. >From d88-jwa@dront.nada.kth.se (Jon W‰tte)
  235. Date: 26 Apr 1994 08:10:11 GMT
  236. Organization: The Royal Institute of Technology
  237.  
  238. In <2phfj0$95h@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  239.  
  240. >Is there any way to determine (through software) if a given machine has a
  241. >CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  242.  
  243. Use the SCSI manager to examine all SCSI devices and look for a CD-ROM
  244. type device.
  245.  
  246. But why? Most users can be trusted to look around their computer, see
  247. "hey, here's a CD-ROM" and check the appropriate check box; that's
  248. several magnitudes safer than any automatic check.
  249.  
  250. And if you're gathering statistics behind the users back, don't.
  251. Remember that Prograph was close to being publicly flogged for the
  252. "Exploding Pink Poodles" stuff, which was something their mastering
  253. company put there.
  254. -- 
  255.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  256.  "Don't Deal with a Dragon."
  257.  
  258. +++++++++++++++++++++++++++
  259.  
  260. >From d88-jwa@dront.nada.kth.se (Jon W‰tte)
  261. Date: 26 Apr 1994 08:11:07 GMT
  262. Organization: The Royal Institute of Technology
  263.  
  264. In <2phl95$i30@unix.sri.com> mxmora@unix.sri.com (Matt Mora) writes:
  265.  
  266. >    osErr = OpenDriver("\p.AppleCD", &ioRefNumTemp);
  267.  
  268. There are other CD-ROM drivers than Apple's CD driver, like
  269. NECs or Toshibas. This solution loses.
  270. -- 
  271.  -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  272.  "Don't Deal with a Dragon."
  273.  
  274. +++++++++++++++++++++++++++
  275.  
  276. >From mxmora@unix.sri.com (Matt Mora)
  277. Date: 26 Apr 1994 10:47:41 -0700
  278. Organization: SRI International, Menlo Park, CA
  279.  
  280. In article <2phnm1$dqm@coyote.csusm.edu> mclow@csusm.edu (Marshall Clow) writes:
  281.  
  282. >Matt,
  283. >    Pardon me if I missed something, but the code that you posted
  284. >only works if the Apple CD-ROM drivers are installed. What if the CD-ROM
  285. >that the user has uses it's own, custom driver?
  286.  
  287.  
  288. Picky, Picky.  Test for non-apple drivers is left as an exercise for the 
  289. reader. :-)
  290.  
  291. I thought that he might want to do something usefull like distribute
  292. his games on CDrom chock full of 32 bit sounds and graphics using driver
  293. calls for access.
  294.  
  295.  
  296.  
  297. Xavier
  298.  
  299.  
  300.  
  301. -- 
  302. ___________________________________________________________
  303. Matthew Xavier Mora                       Matt_Mora@sri.com
  304. SRI International                       mxmora@unix.sri.com
  305. 333 Ravenswood Ave                    Menlo Park, CA. 94025
  306.  
  307. +++++++++++++++++++++++++++
  308.  
  309. >From mkelly@cs.uoregon.edu (Michael A. Kelly)
  310. Date: 26 Apr 1994 11:46:35 -0700
  311. Organization: High Risk Ventures
  312.  
  313. In article <2pii93$hls@news.kth.se>,
  314. Jon W‰tte <d88-jwa@dront.nada.kth.se> wrote:
  315. >Use the SCSI manager to examine all SCSI devices and look for a CD-ROM
  316. >type device.
  317.  
  318. How do I do that?  I've been looking at the SCSI Manager in Think Reference,
  319. and I can't figure out how to tell if the device is a CD ROM device.
  320.  
  321. >Remember that Prograph was close to being publicly flogged for the
  322. >"Exploding Pink Poodles" stuff, which was something their mastering
  323. >company put there.
  324.  
  325. I don't remember anything about that - what happened?
  326.  
  327. We have no intention of making the data we gather public in any way - it's
  328. strictly for our own information.  So that someday in the future when we're
  329. thinking that we'd like to make an action CD game, we can look at our
  330. customer base and see what percentage of action game players have a CD drive.
  331. I don't expect the information to be all that useful, or reliable, but it
  332. doesn't hurt to gather it.
  333.  
  334. Mike.
  335. -- 
  336. _____________________________________________________________________________
  337. Michael A. Kelly                                                President/CEO
  338. mkelly@cs.uoregon.edu                                      High Risk Ventures
  339. _____________________________________________________________________________
  340.  
  341. +++++++++++++++++++++++++++
  342.  
  343. >From isis@netcom.com (Mike Cohen)
  344. Date: Tue, 26 Apr 1994 17:40:03 GMT
  345. Organization: ISIS International
  346.  
  347. mxmora@unix.sri.com (Matt Mora) writes:
  348.  
  349. >In article <2phfj0$95h@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  350. >>
  351. >>Hey,
  352. >>
  353. >>Is there any way to determine (through software) if a given machine has a
  354. >>CD ROM drive attached to it?  Do I just have to look for an unwritable disk
  355. >>larger than 500MB (and wouldn't that only show up if there's a CD mounted)?
  356. >>Is there any other way?
  357.  
  358.  
  359. >Sure,
  360.  
  361. >Here you go:
  362. (code snippet deleted)
  363. >I didn't write it it came from:
  364.  
  365. >// imWare
  366. >// Wednesday, February 14, 1990
  367. >// James Beninghaus
  368.  
  369. This is the cleanest way (I've done it that way myself for an ISO9660 CD
  370. browser), but it will only work for an Apple or compatible drive.
  371. -- 
  372. Mike Cohen - isis@netcom.com
  373. NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
  374.  
  375. +++++++++++++++++++++++++++
  376.  
  377. >From Phil Smy <psmy@io.org>
  378. Date: 27 Apr 1994 13:50:26 GMT
  379. Organization: Innotech MultiMedia Corp.
  380.  
  381. In article <2piiar$hlt@news.kth.se> Jon W!tte, d88-jwa@dront.nada.kth.se
  382. writes:
  383. >>    osErr = OpenDriver("\p.AppleCD", &ioRefNumTemp);
  384. >
  385. >There are other CD-ROM drivers than Apple's CD driver, like
  386. >NECs or Toshibas. This solution loses.
  387.  
  388. Actually, for some reason, with NEC drivers this does work! They must
  389. register themselves (actually I think all cd drivers do) as ".AppleCD".
  390.  
  391. Phil
  392. ******************************************************************
  393. * Phil Smy                    * Interactive CDRom MultiMedia     *
  394. * Sr. Developer               * #include <stddisclaimer.h>       *
  395. * Innotech MultiMedia Corp.   * Wot Gorilla?                     *
  396. ******************************************************************
  397.  
  398. +++++++++++++++++++++++++++
  399.  
  400. >From sch@unx.sas.com (Steve Holzworth)
  401. Date: Wed, 27 Apr 1994 21:10:12 GMT
  402. Organization: SAS Institute Inc.
  403.  
  404. mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  405.  
  406. >In article <2pii93$hls@news.kth.se>,
  407. >Jon W‰tte <d88-jwa@dront.nada.kth.se> wrote:
  408. >>Use the SCSI manager to examine all SCSI devices and look for a CD-ROM
  409. >>type device.
  410.  
  411. >How do I do that?  I've been looking at the SCSI Manager in Think Reference,
  412. >and I can't figure out how to tell if the device is a CD ROM device.
  413.  
  414. The SCSI "Inquiry" command returns info about the specified SCSI device,
  415. including a code which says that it is a ROM, WORM, DISK, etc.
  416.  
  417. A peripheral type  5 should be a CD-ROM drive.
  418. --
  419. Steve Holzworth
  420. sch@unx.sas.com                    "Do not attribute to poor spelling
  421. SAS Institute   x6872               That which is actually poor typing..."
  422. SAS/Macintosh Development Team                            - me
  423. Cary, N.C.
  424.  
  425. +++++++++++++++++++++++++++
  426.  
  427. >From mkelly@cs.uoregon.edu (Michael A. Kelly)
  428. Date: 28 Apr 94 08:30:22 GMT
  429. Organization: High Risk Ventures
  430.  
  431. In article <sch.767481012@gargoyle>, Steve Holzworth <sch@unx.sas.com> wrote:
  432. >
  433. >The SCSI "Inquiry" command returns info about the specified SCSI device,
  434. >including a code which says that it is a ROM, WORM, DISK, etc.
  435.  
  436. OK, but the problem is that I don't have the scsi specs, so I don't know
  437. how to send an inquiry command or get the id from whatever it returns....
  438.  
  439. Mike.
  440. -- 
  441. _____________________________________________________________________________
  442. Michael A. Kelly                                                President/CEO
  443. mkelly@cs.uoregon.edu                                      High Risk Ventures
  444. _____________________________________________________________________________
  445.  
  446. +++++++++++++++++++++++++++
  447.  
  448. >From sch@unx.sas.com (Steve Holzworth)
  449. Date: Thu, 28 Apr 1994 22:37:52 GMT
  450. Organization: SAS Institute Inc.
  451.  
  452. mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
  453.  
  454. >In article <sch.767481012@gargoyle>, Steve Holzworth <sch@unx.sas.com> wrote:
  455. >>
  456. >>The SCSI "Inquiry" command returns info about the specified SCSI device,
  457. >>including a code which says that it is a ROM, WORM, DISK, etc.
  458.  
  459. >OK, but the problem is that I don't have the scsi specs, so I don't know
  460. >how to send an inquiry command or get the id from whatever it returns....
  461.  
  462. I hope you have Macintosh documentation on the SCSI Manager, otherwise
  463. the problem becomes too complex, short of me writing you the actual code
  464. to do the Inquiry. Assuming you DO have the SCSI Manager doc, use a
  465. SCSI command block as follows:
  466.  
  467. The SCSI Inquiry command is command code 0x12.
  468. The command block is as follows (conforms to SCSI2 spec):
  469.  
  470.         Bits
  471.      | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
  472. Byte
  473. 0    Inquiry (0x12)
  474. 1    | LogUnit#  |        0          |
  475. 2        0
  476. 3           0
  477. 4    Allocation Length
  478. 5           0
  479.  
  480. LogUnit# is a logical unit at this SCSI ID, and should almost always be
  481. zero (note, this isn't the same as the SCSI ID itself; it's a sub-unit).
  482.  
  483. Allocation Length is the size of the maximum buffer that should be returned
  484. by this command. You only care about the first byte, so try 1. The Macintosh
  485. is good about throwing away excess bytes and resyncing the SCSI handshake.
  486.  
  487. The first byte returned is the device type, as mentioned in the previous
  488. post.
  489.  
  490. --
  491. Steve Holzworth
  492. sch@unx.sas.com                    "Do not attribute to poor spelling
  493. SAS Institute   x6872               That which is actually poor typing..."
  494. SAS/Macintosh Development Team                            - me
  495. Cary, N.C.
  496.  
  497. +++++++++++++++++++++++++++
  498.  
  499. >From tzs@u.washington.edu (Tim Smith)
  500. Date: 1 May 1994 06:32:31 GMT
  501. Organization: University of Washington School of Law, Class of '95
  502.  
  503. Michael A. Kelly <mkelly@cs.uoregon.edu> wrote:
  504. >How do I do that?  I've been looking at the SCSI Manager in Think Reference,
  505. >and I can't figure out how to tell if the device is a CD ROM device.
  506.  
  507. Try this.  The following was written when Think C first came out with
  508. the objected oriented extensions, and was my first attempt to use
  509. them, which is why it goes a bit overboard.  The first two files
  510. below define an object oriented interface to the SCSI manager.
  511. The third file scans the SCSI bus looking for a tape drive.
  512. At the end, I'll tell you where to change it to look for a
  513. CD-ROM drive.
  514.  
  515. - -------- file cscsi.h ----------
  516.  
  517. #ifndef CSCSI_H
  518. #define    CSCSI_H
  519.  
  520. #include    <SCSI.H>
  521.  
  522. typedef enum
  523. {
  524.     dataIn=1, dataOut=2, noData=3
  525. } XferDir;
  526.  
  527. #define    USE_CDB        0x01
  528. #define    USE_BUF        0x02
  529. #define    USE_LEN        0x04
  530. #define    USE_DIR        0x08
  531. #define    USE_ID        0x10
  532.  
  533. #define    CAN_DATA    (USE_CDB|USE_BUF|USE_LEN|USE_DIR|USE_ID)
  534. #define    CAN_NO_DATA    (USE_CDB|USE_DIR|USE_ID)
  535.  
  536. #define    SCSI_NEED_INFO    (-1)
  537. #define    SCSI_OK            (0)
  538.  
  539. class    CSCSIOp
  540. {
  541.     short    targetID;
  542.     char    cdb[12];
  543.     char    cdbLen;
  544.     unsigned char *    dataPtr;
  545.     long    dataLen;
  546.     short    status;
  547.     short    message;
  548.     OSErr    err;
  549.     XferDir    dir;
  550.     long    timeout;
  551.     int        haveInfo;
  552.     long    moved;
  553. public:
  554.             CSCSIOp( void );
  555.             ~CSCSIOp( void );
  556.     void    keep( int what );
  557.     void    setID( short ID );
  558.     void    setCDB( int len, char * cdbPtr );
  559.     void    set6( char a, char b, char c, char d, char e, char f );
  560.     void    set10( char a, char b, char c, char d, char e, char f,
  561.                     char g, char h, char i, char j );
  562.     void    set12( char a, char b, char c, char d, char e, char f,
  563.                     char g, char h, char i, char j, char k, char l );
  564.     void    setLen( long len );
  565.     void    setBuf( void * buf );
  566.     void    setDir( XferDir direction );
  567.     int        execute( void );
  568.     short    getStatus( void );
  569.     short    getMessage( void );
  570.     void    setTimeout( long newTime );
  571.     OSErr    getErr( void );
  572.     long    getMoved( void );
  573. };
  574.  
  575. #endif
  576.  
  577. - ------ file cscsi.cp ------------
  578.  
  579. #include    "CSCSI.h"
  580. #include    <stdio.h>
  581.  
  582. CSCSIOp::CSCSIOp( void )
  583. {
  584.     haveInfo = 0;
  585.     timeout = 60L;
  586. }
  587.  
  588. CSCSIOp::~CSCSIOp( void )
  589. {
  590. }
  591.  
  592. void    CSCSIOp::keep( int what )
  593. {
  594.     haveInfo = what;
  595. }
  596.  
  597. void    CSCSIOp::setID( short ID )
  598. {
  599.     targetID = ID;
  600.     haveInfo |= USE_ID;
  601. }
  602.  
  603. void    CSCSIOp::setCDB( int len, char * cdbPtr )
  604. {
  605.     int        i;
  606.     cdbLen = len;
  607.     for ( i = 0; i < len; i++ )
  608.         cdb[i] = *cdbPtr++;
  609.     haveInfo |= USE_CDB;
  610. }
  611.  
  612. void    CSCSIOp::set6( char a, char b, char c, char d, char e, char f )
  613. {
  614.     cdbLen = 6;
  615.     cdb[0] = a; cdb[1] = b; cdb[2] = c; cdb[3] = d; cdb[4] = e; cdb[5] = f;
  616.     haveInfo |= USE_CDB;
  617. }
  618.  
  619. void    CSCSIOp::set10( char a, char b, char c, char d, char e, char f,
  620.                 char g, char h, char i, char j )
  621. {
  622.     cdbLen = 10;
  623.     cdb[0] = a; cdb[1] = b; cdb[2] = c; cdb[3] = d; cdb[4] = e; cdb[5] = f;
  624.     cdb[6] = g; cdb[7] = h; cdb[8] = i; cdb[9] = j;
  625.     haveInfo |= USE_CDB;
  626. }
  627.  
  628. void    CSCSIOp::set12( char a, char b, char c, char d, char e, char f,
  629.                 char g, char h, char i, char j, char k, char l )
  630. {
  631.     cdbLen = 12;
  632.     cdb[0] = a; cdb[1] = b; cdb[2] = c; cdb[3] = d; cdb[4] = e; cdb[5] = f;
  633.     cdb[6] = g; cdb[7] = h; cdb[8] = i; cdb[9] = j; cdb[10] = k; cdb[11] = l;
  634.     haveInfo |= USE_CDB;
  635. }
  636.  
  637. void    CSCSIOp::setLen( long len )
  638. {
  639.     dataLen = len;
  640.     haveInfo |= USE_LEN;
  641. }
  642.  
  643. void    CSCSIOp::setBuf( void * buf )
  644. {
  645.     dataPtr = (unsigned char *)buf;
  646.     haveInfo |= USE_BUF;
  647. }
  648.  
  649. void    CSCSIOp::setDir( XferDir direction )
  650. {
  651.     dir = direction;
  652.     haveInfo |= USE_DIR;
  653. }
  654.  
  655. int        CSCSIOp::execute( void )
  656. {
  657.     SCSIInstr    xfer[3];
  658.     int            info = haveInfo;
  659.     
  660.     haveInfo = 0;
  661.     
  662.     if ( info & USE_DIR )
  663.     {
  664.         if ( dir == noData )
  665.         {
  666.             if ( (info & CAN_NO_DATA) != CAN_NO_DATA )
  667.             {
  668.                 return err = SCSI_NEED_INFO;
  669.             }
  670.         }
  671.         else if ( (info & CAN_DATA) != CAN_DATA )
  672.         {
  673.             return err = SCSI_NEED_INFO;
  674.         }
  675.     }
  676.     else
  677.         return err = SCSI_NEED_INFO;
  678.         
  679.     if ( dir != noData )
  680.     {
  681.         //
  682.         // SCSIManager seems to update scParam1 on scInc only if the scInc did
  683.         // not fail.  Thus, if we need to know the exact data count, we need
  684.         // to use a loop, doing on scInc for each byte.
  685.         //
  686.         // If the dataLen is not a multiple of 0x200, we assume the user needs
  687.         // to know the exact amount, and so we loop.  If the dataLen is a multiple
  688.         // of 0x200, we assume it is a read or write to a blocked device, and the
  689.         // user wants efficiency more than an exact byte count.
  690.         //
  691.         if ( dataLen & 0x1ff )
  692.         {
  693.             xfer[0].scOpcode = scInc;
  694.             xfer[0].scParam1 = (unsigned long)dataPtr;
  695.             xfer[0].scParam2 = 1;
  696.             xfer[1].scOpcode = scLoop;
  697.             xfer[1].scParam1 = -10;
  698.             xfer[1].scParam2 = dataLen;
  699.             xfer[2].scOpcode = scStop;
  700.         }
  701.         else
  702.         {
  703.             xfer[0].scOpcode = scInc;
  704.             xfer[0].scParam1 = (unsigned long)dataPtr;
  705.             xfer[0].scParam2 = dataLen;
  706.             xfer[1].scOpcode = scStop;
  707.         }
  708.     }
  709.     
  710.     moved = 0;
  711.     
  712.     err = SCSIGet();
  713.     if ( err )
  714.         return err;
  715.         
  716.     err = SCSISelect( targetID );
  717.     if ( err )
  718.         return err;
  719.         
  720.     err = SCSICmd( (Ptr)cdb, cdbLen );
  721.     if ( err )
  722.     {
  723.         SCSIComplete( &status, &message, 60L );
  724.         return err;
  725.     }
  726.     
  727.     if ( dir == dataIn )
  728.         err = SCSIRead( (Ptr)xfer );
  729.     else if ( dir == dataOut )
  730.         err = SCSIWrite( (Ptr)xfer );
  731.         
  732.     moved = xfer[0].scParam1 - (unsigned long)dataPtr;
  733.     
  734.     if ( err && err != scPhaseErr )
  735.     {
  736.         SCSIComplete( &status, &message, 60L );
  737.         return err;
  738.     }
  739.     
  740.     err = SCSIComplete( &status, &message, timeout );
  741.     
  742.     return err;
  743. }
  744.  
  745. short    CSCSIOp::getStatus( void )
  746. {
  747.     return status;
  748. }
  749.  
  750. short    CSCSIOp::getMessage( void )
  751. {
  752.     return message;
  753. }
  754.  
  755. void    CSCSIOp::setTimeout( long newTime )
  756. {
  757.     timeout = newTime;
  758. }
  759.  
  760. OSErr    CSCSIOp::getErr( void )
  761. {
  762.     return err;
  763. }
  764.  
  765. long    CSCSIOp::getMoved( void )
  766. {
  767.     return moved;
  768. }
  769.  
  770. - ----- excerpt from main.cp ------
  771.  
  772. uchar    buf[256];
  773.  
  774. void    main( void )
  775. {
  776.     long    i;
  777.     int        id;
  778.     CSCSIOp    * inq = new CSCSIOp;
  779.     CSCSIOp * cmd = new CSCSIOp;
  780.     CSCSIOp * rew = new CSCSIOp;
  781.     CSCSIOp * load = new CSCSIOp;
  782.     CSCSIOp * sense = new CSCSIOp;
  783.     
  784.     cout << "Tape drive simple test v0.00" << endl;
  785.     
  786.     inq->set6( 18, 0, 0, 0, 255, 0 );
  787.     inq->setBuf( buf );
  788.     inq->setLen( 255 );
  789.     inq->setDir( dataIn );
  790.     
  791.     //
  792.     // Find the tape drive
  793.     //
  794.     for ( id = 0; id < 7; id++ )
  795.     {
  796.         //
  797.         //First, we issue an INQUIRY to see what kind of device it is.
  798.         //
  799.         inq->keep( USE_CDB | USE_DIR | USE_BUF | USE_LEN );
  800.         inq->setID( id );
  801.         inq->execute();
  802.         if ( inq->getErr() )
  803.             continue;
  804.         //
  805.         // Byte 0 of INQUIRY data contains the device type.
  806.         //
  807.         if ( (buf[0] & 0x1f) == 1 )
  808.         {
  809.             //
  810.             // It's a tape drive
  811.             //
  812.  
  813. - ------------
  814.  
  815. See that "== 1" in that last if statement?  That's where it's checking
  816. for a tape drive.  Change that to 5 for CD-ROM.  If you really want
  817. to be complete, here are the possible devices:
  818.  
  819.     0    Direct-access device (disk)
  820.     1    Sequential-access device (tape)
  821.     2    Printer
  822.     3    Processor
  823.     4    Write-once device (some optical disks)
  824.     5    CD-ROM
  825.     6    Scanner
  826.     7    Optical memory (some optical disks)
  827.     8    Medium changer
  828.     9    Communications
  829.     10-11    Graphic Arts Pre-Press devices
  830.  
  831. --Tim Smith
  832.  
  833. ---------------------------
  834.  
  835. >From krame893@cs.uidaho.edu (Brian Kramer)
  836. Subject: Lex and Yacc for Mac Programmers
  837. Date: 28 Apr 1994 16:54:36 GMT
  838. Organization: University of Idaho, Moscow, Idaho
  839.  
  840. As the title implies, I am looking for lex and yacc (or their equivalents)
  841. for using for a Mac-based parser of mine.
  842.  
  843. If anyone can give an ftp address, or least let me know that they exist,
  844. I would be _extremely_ appreciative!
  845.  
  846. Brian
  847.  
  848.  
  849.  
  850. =                            =
  851. Brian Kramer
  852. krame893@cs.uidaho.edu
  853. Laboratory for Applied Logic
  854. University of Idaho
  855. Moscow, ID
  856. =                            =
  857.  
  858. +++++++++++++++++++++++++++
  859.  
  860. >From neeri@iis.ee.ethz.ch (Matthias Neeracher)
  861. Date: 29 Apr 94 18:07:22
  862. Organization: Integrated Systems Laboratory, ETH, Zurich
  863.  
  864. In article <2popoc$3hu@owl.csrv.uidaho.edu>, krame893@cs.uidaho.edu (Brian Kramer) writes:
  865.  
  866. > As the title implies, I am looking for lex and yacc (or their equivalents)
  867. > for using for a Mac-based parser of mine.
  868.  
  869. Try:
  870.  
  871. ftp://ftp.switch.ch/software/mac/src/mpw_c/bison-1.22.sit.bin
  872. ftp://ftp.switch.ch/software/mac/src/think_c/Bison-1.18.cpt.bin
  873.  
  874. ftp://ftp.switch.ch/software/mac/src/mpw_c/MPW_Perl_bYacc_181.sit.bin
  875. ftp://ftp.switch.ch/software/mac/src/think_c/BYacc-1.8.2.cpt
  876.  
  877. ftp://ftp.switch.ch/software/mac/src/mpw_c/flex-2.3.8.sit.bin
  878. ftp://ftp.switch.ch/software/mac/src/think_c/Flex-2.3.7.cpt.bin
  879.  
  880. BYacc and Bison are Yacc equivalents. Bison has more faetures, BYacc generates
  881. code without legal restrictions on it. Flex is a lex equivalent.
  882.  
  883. Matthias
  884.  
  885. - ---
  886. Matthias Neeracher                                   neeri@iis.ethz.ch
  887.    "Have you heard of the new Cambridge compilers ? They distribute
  888.     gear-wear much more evenly"
  889.         -- William Gibson/Bruce Sterling, _The Difference Engine_
  890.  
  891.  
  892. +++++++++++++++++++++++++++
  893.  
  894. >From krame893@cs.uidaho.edu (Brian Kramer)
  895. Date: 29 Apr 1994 21:59:55 GMT
  896. Organization: University of Idaho, Moscow, Idaho
  897.  
  898. I have received responses from several people.  I was able to locate
  899. Bison and Yacc (on sumex, umich, among several other places).  Thank
  900. you to those who helped me out.
  901.  
  902. Brian
  903.  
  904.  
  905. : =                            =
  906. : Brian Kramer
  907. : krame893@cs.uidaho.edu
  908. : Laboratory for Applied Logic
  909. : University of Idaho
  910. : Moscow, ID
  911. : =                            =
  912.  
  913. ---------------------------
  914.  
  915. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  916. Subject: PowerMac FP performance - interesting results????
  917. Date: 26 Apr 94 20:59:59 GMT
  918. Organization: University of Victoria
  919.  
  920. G'day folks,
  921.  
  922. I recently got a new toy, a PowerMac 6100 based on the Motorola/IBM/
  923. Apple PowerPC 601 chip. Of course, I was curious how fast it really
  924. was so I have done a bit of benchmarking on my own to see just what
  925. it can do. Some people may have been following the thread about slow
  926. floating point performance using sin/cos over the last week or so. This
  927. little test is similar to that except that it does not use sin/cos.
  928. Here are the results that I have seen thus far.
  929.  
  930. Timing statistics for a numerically intensive computation: 
  931.  
  932. The code performs typical 3D shading calculations (as would be found in a 3D
  933. renderer such as a ray tracer or scan-line renderer) a whole bunch of times
  934. in a tight loop. Timings were done on a IBM RS6000 (POWERStation 375) a
  935. SPARC 10, a SPARC 2 GX, a PowerMac 7100 (PowerPC @ 66Mhz), a PowerMac 6100 
  936. (PowerPC @ 60Mhz), a Quadra 840 (68040 @ 40MHz), and a NeXTstation
  937. (68040 @ ??Mhz).
  938.  
  939. Optimization codes for CodeWarrior are:
  940.  
  941. Peep == peephole optimization
  942. Glob == global optimization
  943. IS   == instruction shceduling
  944.  
  945. Machine           Time (seconds)    Compiler        Optimization?
  946. =====================================================================
  947. RS6000            4.1        xlC        -O2
  948. RS6000            4.1        xlC        -O
  949. RS6000            4.9        xlC        none
  950. RS6000            5.1        xlC        -g
  951.  
  952. SPARC 10        4.7        acc        -O2 libm.il
  953. SPARC 10        4.9        acc        -O2
  954. SPARC 10        4.9        acc        -O
  955. SPARC 10        5.6        acc        none
  956. SPARC 10        5.7        acc        -g
  957.  
  958. SPARC 2GX        11.6        acc        -O2
  959. SPARC 2GX        13.9        acc        none
  960.  
  961. PowerMac 7100        12        CodeWarrior    some??
  962. PowerMac 6100        16.52        CodeWarrior    Peep
  963. PowerMac 6100        16.56        CodeWarrior    Peep + Glob
  964. PowerMac 6100        16.43        CodeWarrior    Peep + Glob + IS
  965. PowerMac 6100        16.15        CodeWarrior    Peep + Glob + IS
  966.                             No extensions
  967.  
  968. NeXTstation        32.9        gcc        -O2
  969.  
  970. Quadra 840        34        Symantec    All
  971.  
  972.  
  973. So what does this mean??? You got me, but its interesting. A few things
  974. to note with the above numbers. I know a fair bit about how to get as
  975. much floating point grunt out of the SPARC 10 so those numbers might be
  976. a bit lower than they should (especially due to the use of inline functions
  977. for math (libm.il)). The PowerMac numbers I achieved are also worthy of
  978. comment. I don't know much about getting performance out of the Mac. Are
  979. there special libraries to link in that are faster???? Also, the
  980. CodeWarrior compiler I have is a Beta release and Metrowerks (the company
  981. that makes it) states clearly that their optimizations are 
  982. minimal at this time. Thus no matter what optimizations I used, the
  983. time did not change significantly. Also, neither the PM 7100 or the PM 6100
  984. have a Level 2 instruction cache. This is supposed to increase the
  985. performance of the machine quite drastically. Anyone out there at UVic
  986. got a PowerMac 8100 that I can run this test on (the 8100 comes standard
  987. with the Level 2 cache).
  988.  
  989. What else have I noticed? If you can avoid it, DO NOT use sin/cos/tan
  990. on the PowerMacs, their implementation is terribly slow. A similar
  991. test to the one above results in the PowerMac being slower than the
  992. Quadra 840AV. Strange, but true....
  993.  
  994. Overall, I am a bit disapointed that the performance wasn't a bit closer
  995. to the SPARC 10 and further from the 68040 based machines. That is what
  996. I would have expected, but that mat be explainable by the 60Mhz clock
  997. on my machine and no Level 2 cache.
  998.  
  999. Any comments????
  1000.  
  1001.     Brian
  1002.  
  1003.  
  1004.  
  1005. --
  1006.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1007. Under the most rigorously controlled conditions of pressure, temperature,
  1008. volume, humidity and other variables, the organism will do as it damn well
  1009. pleases. Sounds like some of the code I have written......  8-)
  1010.  
  1011. +++++++++++++++++++++++++++
  1012.  
  1013. >From tmcgrath@netcom10.netcom.com (Timothy McGrath)
  1014. Date: Wed, 27 Apr 1994 23:20:27 GMT
  1015. Organization: NETCOM On-line services
  1016.  
  1017. In article <bcorrie.767393999@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1018.  
  1019. >Machine           Time (seconds)    Compiler        Optimization?
  1020. >=====================================================================
  1021. >RS6000            4.1        xlC        -O2
  1022. >RS6000            4.1        xlC        -O
  1023. >RS6000            4.9        xlC        none
  1024. >RS6000            5.1        xlC        -g
  1025. >
  1026. >SPARC 10        4.7        acc        -O2 libm.il
  1027. >SPARC 10        4.9        acc        -O2
  1028. >SPARC 10        4.9        acc        -O
  1029. >SPARC 10        5.6        acc        none
  1030. >SPARC 10        5.7        acc        -g
  1031. >
  1032. >SPARC 2GX        11.6        acc        -O2
  1033. >SPARC 2GX        13.9        acc        none
  1034. >
  1035. >PowerMac 7100        12        CodeWarrior    some??
  1036. >PowerMac 6100        16.52        CodeWarrior    Peep
  1037. >PowerMac 6100        16.56        CodeWarrior    Peep + Glob
  1038. >PowerMac 6100        16.43        CodeWarrior    Peep + Glob + IS
  1039. >PowerMac 6100        16.15        CodeWarrior    Peep + Glob + IS
  1040. >                            No extensions
  1041. >
  1042. >NeXTstation        32.9        gcc        -O2
  1043. >
  1044. >Quadra 840        34        Symantec    All
  1045. >
  1046.  
  1047. These very interesting numeric results are showing surprisingly poor PPC
  1048. performance in comparison to Sun and IBM RISC workstations. The results are
  1049. at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1050.  
  1051. >So what does this mean??? You got me, but its interesting. A few things
  1052.  
  1053. This continues a pattern that I've long observed: there seems to be
  1054. something about the Mac that produces poor performance using standard
  1055. compilers (MPW, Symantic, or CW).  For instance, the deleted figures show
  1056. that a 25 MHz 68040 NeXT does the computation faster than the 40Mhz 68040
  1057. in the Quadra 840AV.
  1058.  
  1059. I compiled POV-Ray, a popular freeware raytracer, on a 25Mhz 68040 unix box
  1060. and compared POV-Ray's performance to my own 33Mhz 68040-based Mac
  1061. (with cache; Symantec C 6.0). The results for such a floating-point
  1062. intensive application: the Unix box won by being 30% faster!! (Worse still,
  1063. yer bog $1500 486-66 runs the same app about 50% faster than the Unix box).
  1064.  
  1065. I don't know if the problem is poor compiler optimization, poor runtime
  1066. libraries, poor performance out of system software, or bottlenecks in the Mac
  1067. hardware. I'm about the biggest Mac fan there is, and I'm really unhappy
  1068. that my favorite computer is such a performance dog.
  1069. -- 
  1070. Tim McGrath ----- tmcgrath@netcom.com ----- "Minimalist signaturist"
  1071.  
  1072. +++++++++++++++++++++++++++
  1073.  
  1074. >From greer@utdallas.edu (Dale M. Greer)
  1075. Date: 28 Apr 1994 03:45:38 GMT
  1076. Organization: The University of Texas at Dallas
  1077.  
  1078. Brian  Corrie (bcorrie@csr.UVic.CA) wrote:
  1079. > G'day folks,
  1080.  
  1081. > Timing statistics for a numerically intensive computation: 
  1082.  
  1083. > The code performs typical 3D shading calculations (as would be found in a 3D
  1084. > renderer such as a ray tracer or scan-line renderer) a whole bunch of times
  1085. > in a tight loop. Timings were done on a IBM RS6000 (POWERStation 375) a
  1086. > SPARC 10, a SPARC 2 GX, a PowerMac 7100 (PowerPC @ 66Mhz), a PowerMac 6100 
  1087. > (PowerPC @ 60Mhz), a Quadra 840 (68040 @ 40MHz), and a NeXTstation
  1088. > (68040 @ ??Mhz).
  1089.  
  1090. > Optimization codes for CodeWarrior are:
  1091.  
  1092. > Peep == peephole optimization
  1093. > Glob == global optimization
  1094. > IS   == instruction shceduling
  1095.  
  1096. But are you using SANE on the Mac?
  1097.  
  1098. [...]
  1099. > What else have I noticed? If you can avoid it, DO NOT use sin/cos/tan
  1100. > on the PowerMacs, their implementation is terribly slow. A similar
  1101. > test to the one above results in the PowerMac being slower than the
  1102. > Quadra 840AV. Strange, but true....
  1103.  
  1104. Bummer!  Sounds like SANE.  I once wrote a floating point library for
  1105. the 68K that had a sin/cos/tan about 10 times faster than SANE.  The
  1106. PowerMac doesn't have to be that slow.  Maybe MetroWerks will tap IBM
  1107. for a good algorithm.
  1108.  
  1109. --
  1110.  
  1111. Dale Greer, greer@utdallas.edu
  1112. "They know that it is human nature to take up causes whereby a man may
  1113.  oppress his neighbor, no matter how unjustly. ... Hence they have had
  1114.  no trouble in finding men who would preach the damnability and heresy
  1115.  of the new doctrine from the very pulpit..." - Galileo Galilei, 1615
  1116.  
  1117.  
  1118. +++++++++++++++++++++++++++
  1119.  
  1120. >From sdoran@cis.ksu.edu (Steven D. Marcotte)
  1121. Date: 28 Apr 94 06:29:45 GMT
  1122. Organization: Kansas State University
  1123.  
  1124. tmcgrath@netcom10.netcom.com (Timothy McGrath) writes:
  1125.  
  1126. >In article <bcorrie.767393999@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1127.  
  1128. >>Machine           Time (seconds)    Compiler        Optimization?
  1129. >>=====================================================================
  1130. >>RS6000            4.1        xlC        -O2
  1131. >>RS6000            4.1        xlC        -O
  1132. >>RS6000            4.9        xlC        none
  1133. >>RS6000            5.1        xlC        -g
  1134. >>
  1135. >>SPARC 10        4.7        acc        -O2 libm.il
  1136. >>SPARC 10        4.9        acc        -O2
  1137. >>SPARC 10        4.9        acc        -O
  1138. >>SPARC 10        5.6        acc        none
  1139. >>SPARC 10        5.7        acc        -g
  1140. >>
  1141. >>SPARC 2GX        11.6        acc        -O2
  1142. >>SPARC 2GX        13.9        acc        none
  1143. >>
  1144. >>PowerMac 7100        12        CodeWarrior    some??
  1145. >>PowerMac 6100        16.52        CodeWarrior    Peep
  1146. >>PowerMac 6100        16.56        CodeWarrior    Peep + Glob
  1147. >>PowerMac 6100        16.43        CodeWarrior    Peep + Glob + IS
  1148. >>PowerMac 6100        16.15        CodeWarrior    Peep + Glob + IS
  1149. >>                            No extensions
  1150. >>
  1151. >>NeXTstation        32.9        gcc        -O2
  1152. >>
  1153. >>Quadra 840        34        Symantec    All
  1154. >>
  1155.  
  1156. >These very interesting numeric results are showing surprisingly poor PPC
  1157. >performance in comparison to Sun and IBM RISC workstations. The results are
  1158. >at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1159.  
  1160. >>So what does this mean??? You got me, but its interesting. A few things
  1161.  
  1162. >This continues a pattern that I've long observed: there seems to be
  1163. >something about the Mac that produces poor performance using standard
  1164. >compilers (MPW, Symantic, or CW).  For instance, the deleted figures show
  1165. >that a 25 MHz 68040 NeXT does the computation faster than the 40Mhz 68040
  1166. >in the Quadra 840AV.
  1167.  
  1168.     I may be way off here but, with Symantec C++ at least, you can
  1169. compile a straight ANSI C program.  If you do, the compiler will
  1170. generate a window for you to do I/O with, I assume with an appropriate
  1171. event loop.  I would imagine this is where a lot of the slow down is,
  1172. waiting for events.  If you are ambitious, try porting your stuff so
  1173. don't wait for events until all your calculations are done and see how
  1174. that compairs.
  1175.  
  1176. Steven
  1177.  
  1178. -- 
  1179.  
  1180.                                         Steven Marcotte
  1181.                                         sdoran@cis.ksu.edu
  1182.  
  1183. +++++++++++++++++++++++++++
  1184.  
  1185. >From palais@binah.cc.brandeis.edu
  1186. Date: Thu, 28 Apr 1994 13:00:21 GMT
  1187. Organization: Brandeis University
  1188.  
  1189. It seems to be pretty "well-known" that the reason that SANE has
  1190. a reputation for being slow is connected mainly with a few
  1191. transcendental functions which, to get the guaranteed accuracy
  1192. need a lot of computation. Most of the basic routines are in fact
  1193. quite fast. Since for most purposes SANE accuracy is overkill,
  1194. but SANE is still a better way to go than direct FPU calls 
  1195. (for compatibility reasons---particularly with the PowerPC), 
  1196. the obvious approach is to re-write these transcendental functions
  1197. using lower tolerances. I'm sure this is no big deal---one could
  1198. crib the algorithms from Numerical Recipes or IMSL. But just what
  1199. are the offending routines? I assume they are sin and cos, but does
  1200. anyone really know?
  1201.  
  1202. +++++++++++++++++++++++++++
  1203.  
  1204. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1205. Date: 28 Apr 94 19:05:36 GMT
  1206. Organization: University of Victoria
  1207.  
  1208. tmcgrath@netcom10.netcom.com (Timothy McGrath) writes:
  1209. >In article <bcorrie.767393999@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1210.  
  1211. >>Machine           Time (seconds)    Compiler        Optimization?
  1212. >>=====================================================================
  1213. >>RS6000            4.1        xlC        -O2
  1214. >>RS6000            4.1        xlC        -O
  1215. >>RS6000            4.9        xlC        none
  1216. >>RS6000            5.1        xlC        -g
  1217. >>
  1218. >>SPARC 10        4.7        acc        -O2 libm.il
  1219. >>SPARC 10        4.9        acc        -O2
  1220. >>SPARC 10        4.9        acc        -O
  1221. >>SPARC 10        5.6        acc        none
  1222. >>SPARC 10        5.7        acc        -g
  1223. >>
  1224. >>SPARC 2GX        11.6        acc        -O2
  1225. >>SPARC 2GX        13.9        acc        none
  1226. >>
  1227. >>PowerMac 7100        12        CodeWarrior    some??
  1228. >>PowerMac 6100        16.52        CodeWarrior    Peep
  1229. >>PowerMac 6100        16.56        CodeWarrior    Peep + Glob
  1230. >>PowerMac 6100        16.43        CodeWarrior    Peep + Glob + IS
  1231. >>PowerMac 6100        16.15        CodeWarrior    Peep + Glob + IS
  1232. >>                            No extensions
  1233. >>
  1234. >>NeXTstation        32.9        gcc        -O2
  1235. >>
  1236. >>Quadra 840        34        Symantec    All
  1237. >>
  1238.  
  1239. >These very interesting numeric results are showing surprisingly poor PPC
  1240. >performance in comparison to Sun and IBM RISC workstations. The results are
  1241. >at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1242.  
  1243. The processor used in the IEEE article (I assume you are talking about
  1244. "The New Contenders", December 1993) is an 80 MHz 601. I wouldn't be
  1245. surprised if it had a cache as well (not clear to me in the table on
  1246. page 21). Thus this would be a similar setup to that in the 8100. I haven't
  1247. seen a test result from such a machine yet so hopefully it will be better.
  1248. It may turn out that with good optimizations (which CodeWarrior does not do),
  1249. an 80MHz 601, and a level 2 cache, the PowerMac's might come close to
  1250. the SPARC 10 as one would expect/hope. I am not ready to moan about the
  1251. performance just yet....  8-)  I will include the code I used below
  1252. if anyone with an 8100 wants to try it out....
  1253.  
  1254. >>So what does this mean??? You got me, but its interesting. A few things
  1255.  
  1256. >This continues a pattern that I've long observed: there seems to be
  1257. >something about the Mac that produces poor performance using standard
  1258. >compilers (MPW, Symantic, or CW).  For instance, the deleted figures show
  1259. >that a 25 MHz 68040 NeXT does the computation faster than the 40Mhz 68040
  1260. >in the Quadra 840AV.
  1261.  
  1262. Hopefully, the compilers will get better.... the sooner the better.
  1263.  
  1264. >I don't know if the problem is poor compiler optimization, poor runtime
  1265. >libraries, poor performance out of system software, or bottlenecks in the Mac
  1266. >hardware. I'm about the biggest Mac fan there is, and I'm really unhappy
  1267. >that my favorite computer is such a performance dog.
  1268.  
  1269. I would say a bit of each of the above. As time goes by hopefully the
  1270. various groups involved (Apple, Compiler types, etc.) will spend more
  1271. time optimizing for the new machines. Libraries will improve over time.
  1272. Hopefully the compilers will improve very quickly....
  1273.  
  1274.     Brian
  1275.  
  1276. ======================================================================
  1277.  
  1278.  
  1279. /* Note this is the UNIX version of the code. I used TickCount()
  1280.    on the Mac to get my timing results.
  1281.  */
  1282.  
  1283. #include <stdio.h>
  1284. #include <math.h>
  1285.  
  1286. #define SL_VECDOT( A,B )   ((A)[0]*(B)[0]+(A)[1]*(B)[1]+(A)[2]*(B)[2])
  1287. #define SL_VECLEN( A )     (sqrt((A)[0]*(A)[0]+(A)[1]*(A)[1]+(A)[2]*(A)[2]))
  1288. #define SL_VECCROSS( A,B,C ) \
  1289.     {                     \
  1290.          (C)[0] = (A)[1]*(B)[2] - (A)[2]*(B)[1] ; \
  1291.          (C)[1] = (A)[2]*(B)[0] - (A)[0]*(B)[2] ; \
  1292.          (C)[2] = (A)[0]*(B)[1] - (A)[1]*(B)[0] ; \
  1293.     }
  1294. #define SL_VECMULT( a,A,B ) \
  1295.     {                    \
  1296.          (B)[0]=(a)*(A)[0] ; \
  1297.          (B)[1]=(a)*(A)[1] ; \
  1298.          (B)[2]=(a)*(A)[2] ; \
  1299.     }
  1300. #define SL_VECDIV( a,A,B ) \
  1301.     {                    \
  1302.          (B)[0]=(A)[0]/(a) ; \
  1303.          (B)[1]=(A)[1]/(a) ; \
  1304.          (B)[2]=(A)[2]/(a) ; \
  1305.     }
  1306.  
  1307. #define SL_VECADD( A,B,C ) \
  1308.     {                   \
  1309.         (C)[0]=(A)[0]+(B)[0] ; \
  1310.         (C)[1]=(A)[1]+(B)[1] ; \
  1311.         (C)[2]=(A)[2]+(B)[2] ; \
  1312.     }
  1313.  
  1314. #define SL_VECADDS( a,A,B,C ) \
  1315.     {                      \
  1316.          (C)[0] = (a) * (A)[0] + (B)[0] ; \
  1317.          (C)[1] = (a) * (A)[1] + (B)[1] ; \
  1318.          (C)[2] = (a) * (A)[2] + (B)[2] ; \
  1319.     }
  1320.  
  1321.  
  1322. main(argc, argv)
  1323.   int argc;
  1324.   char **argv;
  1325. {
  1326.   register int i;
  1327.   register int MAXI;
  1328.   double N[3], L[3], Cl[3], C[3];
  1329.   double len, dot;
  1330.  
  1331.   N[0] = 1.0;
  1332.   N[1] = 2.0;
  1333.   N[2] = 3.5;
  1334.   L[0] = 1.8;
  1335.   L[1] = 0.2;
  1336.   L[2] = 1.4;
  1337.   Cl[0] = 1.5;
  1338.   Cl[1] = -0.2;
  1339.   Cl[2] = 1.9;
  1340.   C[0] = 0.0;
  1341.   C[1] = 0.0;
  1342.   C[2] = 0.0;
  1343.  
  1344.   if (argc < 2) MAXI = 1000;
  1345.   else MAXI = atoi(argv[1]);
  1346.   printf("Loop count = %d\n", MAXI);
  1347.  
  1348.   for(i=0 ; i<MAXI ; i++)
  1349.   {
  1350.     len = sqrt(SL_VECDOT(N, N));
  1351.     if (len != 0.0) SL_VECDIV(len, N, N);
  1352.  
  1353.     len = sqrt(SL_VECDOT(L, L));
  1354.     if (len != 0.0) SL_VECDIV(len, L, L);
  1355.  
  1356.     dot = SL_VECDOT(N, L);
  1357.     if (dot > 0.0) SL_VECADDS(dot, Cl, C, C);
  1358.  
  1359.   }
  1360.   printf("Color = %g, %g, %g\n", C[0], C[1], C[2]);
  1361. }
  1362.  
  1363.  
  1364. --
  1365.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1366. Under the most rigorously controlled conditions of pressure, temperature,
  1367. volume, humidity and other variables, the organism will do as it damn well
  1368. pleases. Sounds like some of the code I have written......  8-)
  1369.  
  1370. +++++++++++++++++++++++++++
  1371.  
  1372. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1373. Date: 28 Apr 94 19:20:05 GMT
  1374. Organization: University of Victoria
  1375.  
  1376. greer@utdallas.edu (Dale M. Greer) writes:
  1377.  
  1378. >Brian  Corrie (bcorrie@csr.UVic.CA) wrote:
  1379. >> G'day folks,
  1380.  
  1381. >> Timing statistics for a numerically intensive computation: 
  1382.  
  1383. >> The code performs typical 3D shading calculations (as would be found in a 3D
  1384. >> renderer such as a ray tracer or scan-line renderer) a whole bunch of times
  1385. >> in a tight loop. Timings were done on a IBM RS6000 (POWERStation 375) a
  1386. >> SPARC 10, a SPARC 2 GX, a PowerMac 7100 (PowerPC @ 66Mhz), a PowerMac 6100 
  1387. >> (PowerPC @ 60Mhz), a Quadra 840 (68040 @ 40MHz), and a NeXTstation
  1388. >> (68040 @ ??Mhz).
  1389.  
  1390. >> Optimization codes for CodeWarrior are:
  1391.  
  1392. >> Peep == peephole optimization
  1393. >> Glob == global optimization
  1394. >> IS   == instruction shceduling
  1395.  
  1396. >But are you using SANE on the Mac?
  1397.  
  1398. Not as far as I know. Just doing multiplies, adds, divisions, and one sqrt
  1399. per iteration through the loop. I posted the code in response to another
  1400. article in this thread if anyone is interested.
  1401.  
  1402.     Brian
  1403. --
  1404.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1405. Under the most rigorously controlled conditions of pressure, temperature,
  1406. volume, humidity and other variables, the organism will do as it damn well
  1407. pleases. Sounds like some of the code I have written......  8-)
  1408.  
  1409. +++++++++++++++++++++++++++
  1410.  
  1411. >From nagle@netcom.com (John Nagle)
  1412. Date: Thu, 28 Apr 1994 19:19:56 GMT
  1413. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  1414.  
  1415. palais@binah.cc.brandeis.edu writes:
  1416. >It seems to be pretty "well-known" that the reason that SANE has
  1417. >a reputation for being slow is connected mainly with a few
  1418. >transcendental functions which, to get the guaranteed accuracy
  1419. >need a lot of computation. Most of the basic routines are in fact
  1420. >quite fast. Since for most purposes SANE accuracy is overkill,
  1421. >but SANE is still a better way to go than direct FPU calls 
  1422. >(for compatibility reasons---particularly with the PowerPC), 
  1423.  
  1424.       Nah.  You're guaranteed that an FPU is present on PPC, so use it.
  1425. Worse, "double" using SANE is 80 bits, and the PPC has only 64-bit
  1426. floating point hardware, which makes 80-bit floating point expensive.
  1427.  
  1428.       SANE is slow because you spend so much time pushing big floating
  1429. point objects on the stack and taking them off the stack.  You lose
  1430. a factor of 10 with SANE on 68K macs equipped with FPUs for multiply.
  1431.  
  1432.                         John Nagle
  1433.  
  1434. +++++++++++++++++++++++++++
  1435.  
  1436. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1437. Date: 28 Apr 94 23:35:40 GMT
  1438. Organization: University of Victoria
  1439.  
  1440. sdoran@cis.ksu.edu (Steven D. Marcotte) writes:
  1441. >tmcgrath@netcom10.netcom.com (Timothy McGrath) writes:
  1442. >>In article <bcorrie.767393999@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1443. [Bunch of stats deleted]
  1444. >>These very interesting numeric results are showing surprisingly poor PPC
  1445. >>performance in comparison to Sun and IBM RISC workstations. The results are
  1446. >>at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1447.  
  1448. >>>So what does this mean??? You got me, but its interesting. A few things
  1449.  
  1450. >>This continues a pattern that I've long observed: there seems to be
  1451. >>something about the Mac that produces poor performance using standard
  1452. >>compilers (MPW, Symantic, or CW).  For instance, the deleted figures show
  1453. >>that a 25 MHz 68040 NeXT does the computation faster than the 40Mhz 68040
  1454. >>in the Quadra 840AV.
  1455.  
  1456. >    I may be way off here but, with Symantec C++ at least, you can
  1457. >compile a straight ANSI C program.  If you do, the compiler will
  1458. >generate a window for you to do I/O with, I assume with an appropriate
  1459. >event loop.  I would imagine this is where a lot of the slow down is,
  1460. >waiting for events.  If you are ambitious, try porting your stuff so
  1461. >don't wait for events until all your calculations are done and see how
  1462. >that compairs.
  1463.  
  1464. With CodeWarrior, you get a IO window, but as far as I know there is 
  1465. no event loop, the benchmark program is in total control of the machine
  1466. (at least it control mine, short of forcing it to quit). I don't
  1467. think that is the source of much of the slow down anyway. Of course
  1468. I am no expert and may be completely out to lunch 8-)
  1469.  
  1470.     Brian
  1471. --
  1472.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1473. Under the most rigorously controlled conditions of pressure, temperature,
  1474. volume, humidity and other variables, the organism will do as it damn well
  1475. pleases. Sounds like some of the code I have written......  8-)
  1476.  
  1477. +++++++++++++++++++++++++++
  1478.  
  1479. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1480. Date: 28 Apr 94 23:39:19 GMT
  1481. Organization: University of Victoria
  1482.  
  1483. palais@binah.cc.brandeis.edu writes:
  1484. >It seems to be pretty "well-known" that the reason that SANE has
  1485. >a reputation for being slow is connected mainly with a few
  1486. >transcendental functions which, to get the guaranteed accuracy
  1487. >need a lot of computation. Most of the basic routines are in fact
  1488. >quite fast. Since for most purposes SANE accuracy is overkill,
  1489. >but SANE is still a better way to go than direct FPU calls 
  1490. >(for compatibility reasons---particularly with the PowerPC), 
  1491. >the obvious approach is to re-write these transcendental functions
  1492. >using lower tolerances. I'm sure this is no big deal---one could
  1493. >crib the algorithms from Numerical Recipes or IMSL. But just what
  1494. >are the offending routines? I assume they are sin and cos, but does
  1495. >anyone really know?
  1496.  
  1497. So maybe someone can tell me. If I use CodeWarrior, include the ANSI
  1498. library and the MathLibrary, am I using SANE????? I don't think I am,
  1499. but I may be wrong!?!?
  1500.  
  1501. My experiences thus far show that a computation that uses all sin/cos
  1502. calls is HORRIBLY slow on the PowerMacs. Slower even than a Quadra 840.
  1503. And yes, that is native PowerMac code. Obviously the sin/cos implementation
  1504. is faster on the Quadra. Is it a hardware calculation on the Quadra's
  1505. floating point unit, or is it less accurate on the Quadra? You got me,
  1506. but I know its slow on the PowerMac!!
  1507.  
  1508.     Brian
  1509.  
  1510.  
  1511. --
  1512.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1513. Under the most rigorously controlled conditions of pressure, temperature,
  1514. volume, humidity and other variables, the organism will do as it damn well
  1515. pleases. Sounds like some of the code I have written......  8-)
  1516.  
  1517. +++++++++++++++++++++++++++
  1518.  
  1519. >From nagle@netcom.com (John Nagle)
  1520. Date: Fri, 29 Apr 1994 02:09:29 GMT
  1521. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  1522.  
  1523. bcorrie@csr.UVic.CA (Brian  Corrie) answers the question:
  1524. >>But are you using SANE on the Mac?
  1525.  
  1526. >Not as far as I know. Just doing multiplies, adds, divisions, and one sqrt
  1527. >per iteration through the loop. I posted the code in response to another
  1528. >article in this thread if anyone is interested.
  1529.  
  1530.       Try using 8-byte doubles and see if things improve.  PPC doesn't have
  1531. an 80-bit FPU, so 80-bit performance suffers.  Or try using "float" instead
  1532. of "double", which consistently gets you 32-bit floats on all Apple
  1533. platforms.
  1534.  
  1535.                     John Nagle
  1536.  
  1537. +++++++++++++++++++++++++++
  1538.  
  1539. >From 103t_english@west.cscwc.pima.edu
  1540. Date: 29 Apr 94 03:09:48 MST
  1541. Organization: (none)
  1542.  
  1543. In article <1994Apr28.130021.22832@news.cs.brandeis.edu>, palais@binah.cc.brandeis.edu writes:
  1544. > It seems to be pretty "well-known" that the reason that SANE has
  1545. > a reputation for being slow is connected mainly with a few
  1546. > transcendental functions which, to get the guaranteed accuracy
  1547. > need a lot of computation. Most of the basic routines are in fact
  1548. > quite fast. Since for most purposes SANE accuracy is overkill,
  1549. > but SANE is still a better way to go than direct FPU calls 
  1550. > (for compatibility reasons---particularly with the PowerPC), 
  1551. > the obvious approach is to re-write these transcendental functions
  1552. > using lower tolerances. I'm sure this is no big deal---one could
  1553. > crib the algorithms from Numerical Recipes or IMSL. But just what
  1554. > are the offending routines? I assume they are sin and cos, but does
  1555. > anyone really know?
  1556.  
  1557.  
  1558. IF the FPU is present on a 68K Mac, the SANE calls will use it, but only for
  1559. arithmetic. All other SANE calls are done using Apple's own libraries (using
  1560. the fpu for addition/subtraction/etc).
  1561.  
  1562. The overhead from SANE also comes from the fact that it is called via the Trap
  1563. Dispatcher, instead of directly, and that translations between the SANE format
  1564. and the 68881 format need to be done.
  1565.  
  1566.  
  1567. Lawson
  1568.  
  1569. +++++++++++++++++++++++++++
  1570.  
  1571. >From sparent@mv.us.adobe.com (Sean Parent)
  1572. Date: Sat, 30 Apr 1994 00:02:02 GMT
  1573. Organization: Adobe Systems Incorporated
  1574.  
  1575. This is getting awfully messy. The original discussion was talking about
  1576. native floating point performance. Some how the question of SANE came up.
  1577. Let me list some info:
  1578.  
  1579. • On 68K machines w/o an FPU, SANE is a software floating point package
  1580. implemented using integer arithmetic and provides 80bit "extended" floating
  1581. point support. For most (all) operations, floating point types (whether
  1582. double, single, comp, etc.) promote to 80 bit extendes for maximal
  1583. accuracy. Hence, using 80 bit extendeds tends to be fastest. SANE is
  1584. invoked via an A-Trap but in recent systems SANE back pages the calling
  1585. code so the A-Trap overhead is only paid on the first invocation.
  1586.  
  1587. • On 68K machines w/ an FPU, SANE is still available and is implement using
  1588. the FPU for those operations that it can and maintain accuracy. The FPU
  1589. (68881/2 or 040) uses 96bit format but 16 bits are unused so converting
  1590. >From 80bit to 96 bit format only requires a shift. Applications can be
  1591. compiled to call the FPU directly and they can check for it via a call to
  1592. Gestalt. On the 040, the transcendental functions are not in the FPU so
  1593. those instructions are handled in software as exceptions.
  1594.  
  1595. • On a Power Mac, running emulated code, there is no emulated FPU so it is
  1596. similar to the first case above except SANE is build into the emulator so
  1597. it is running "native" (though it still only uses integer math to do the fp
  1598. calculations). There is no "Mixed Mode" overhead or A-Trap dispatch
  1599. overhead because SANE is handled as any other instructions (there really
  1600. isn't any "A-Trap" overhead at all on the Power Mac because the A-Trap
  1601. dispatching is handled by the emulator).
  1602.  
  1603. • On a Power Mac, running a "native" application SANE is not available. You
  1604. can't do native 80 or 96bit arithmetic (unless you wan't to implement it
  1605. yourself or call some 68K code to do it). Instead, there is a new numerics
  1606. package based on the NCEG spec. It support most all of what SANE did
  1607. (though a couple of types are missing, like comp) and a bit more. The
  1608. supported types are: float (IEEE single), double (IEEE double), and long
  1609. double (IBM's "double double" which is 128bits and is IEEE extended
  1610. complient).
  1611.  
  1612. A portable application should use floats or doubles for persistent data
  1613. storage (files), float_t or double_t for fast calculations with precision
  1614. and least that of float and double respectively, and long double for
  1615. intermediate results that require extra precision. On the various machines,
  1616. these types are:
  1617.  
  1618.                 68K SANE     68K FPU      PowerPC
  1619. float           32bit        32bit        32bit
  1620. double          64bit        64bit        64bit
  1621. float_t         80bit        96bit        32bit
  1622. double_t        80bit        96bit        64bit
  1623. long double     80bit        96bit       128bit
  1624.  
  1625. Now, I haven't looked at this bench mark that is floating around that shows
  1626. native PPC applications in such bad light but what could attribute to it is
  1627. the compiler (I don't know of a PPC compiler other than xlc that does
  1628. really good FP optimizations), and the floating point library. Last I
  1629. checked Apple's library was a bit slower than IBM's though it was
  1630. considerably more accurate. Someone with some time should compiler the
  1631. "bench mark" with xlc and run it on a PowerMac and time the library
  1632. routines. I know of no reason why there would be any significant difference
  1633. in time between a 66MHz PowerMac and a 66MHz 250 given the same compiler
  1634. and the same libraries.
  1635.  
  1636. -- 
  1637. Sean Parent
  1638.  
  1639. +++++++++++++++++++++++++++
  1640.  
  1641. >From rang@winternet.mpls.mn.us (Anton Rang)
  1642. Date: 29 Apr 1994 23:08:18 GMT
  1643. Organization: Minnesota Angsters
  1644.  
  1645. In article <bcorrie.767576359@tara> bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1646. >So maybe someone can tell me. If I use CodeWarrior, include the ANSI
  1647. >library and the MathLibrary, am I using SANE????? I don't think I am,
  1648. >but I may be wrong!?!?
  1649.  
  1650.   No, you're not using SANE, unless you're compiling for the 68000.
  1651. SANE is only used on the 68000 series.  It's not available on the
  1652. Power Macintoshes except in emulation mode.
  1653.  
  1654. >My experiences thus far show that a computation that uses all sin/cos
  1655. >calls is HORRIBLY slow on the PowerMacs. Slower even than a Quadra 840.
  1656.  
  1657.   Right.  The transcendental functions are sloooooow.  I don't know
  1658. how much of this is related to supporting the NCEG exception model,
  1659. but I suspect an awful lot of is.  (Alternatively, it could be that
  1660. range reduction is implemented poorly?)
  1661.  
  1662.   After all, to a first approximation, computing a sin requires:
  1663.  
  1664.     (i) Range-reduce to (say) 0 to pi/2.
  1665.         This may require a division (slow) if you're out of the range
  1666.         -pi to +pi, but shouldn't be *that* incredibly slow.
  1667.  
  1668.     (ii) Compute a Taylor series (or a more quickly converging one).
  1669.          I'm not sure how many terms would be required, not being up
  1670.          on state-of-the-art numerical algorithms, but probably not
  1671.          more than 5 or so for single precision, perhaps 8-10 for
  1672.          double precision.  These should be multiply-add, relatively
  1673.          fast.
  1674.  
  1675.     (iii) Do a little cleanup depending on the original sign etc.
  1676.  
  1677. >Is it a hardware calculation on the Quadra's
  1678. >floating point unit, or is it less accurate on the Quadra?
  1679.  
  1680.   Neither, as far as I know (not sure about accuracy).  The 68040
  1681. doesn't have built-in transcendental functions; they're implemented in
  1682. software.  Heck, I've been tempted to disassemble the 68040 FPSP, grab
  1683. the appropriate constants, port it to PPC assembly and time the
  1684. result.  It would be *bound* to be faster than the current one.
  1685.  
  1686.   SOMEONE out there must know the story about why MathLib runs so
  1687. slowly.  Is it the exception handling?  There are a bunch of procedure
  1688. calls in it related to that, and handling all of the boundaries right
  1689. undoubtedly requires a lot of work...sigh.  Wish I knew for sure.
  1690. --
  1691. Anton Rang (rang@winternet.mpls.mn.us)
  1692.  
  1693. +++++++++++++++++++++++++++
  1694.  
  1695. >From jwbaxter@olympus.net (John W. Baxter)
  1696. Date: Sun, 01 May 1994 10:32:08 -0700
  1697. Organization: Internet for the Olympic Peninsula
  1698.  
  1699. In article <TMCGRATH.94Apr27162028@netcom10.netcom.com>,
  1700. tmcgrath@netcom10.netcom.com (Timothy McGrath) wrote:
  1701.  
  1702. [Table of results omitted...it's been quoted many times already.]
  1703. > These very interesting numeric results are showing surprisingly poor PPC
  1704. > performance in comparison to Sun and IBM RISC workstations. The results are
  1705. > at clear odds with published specmarks from IEEE Spectrum a few months ago.
  1706. No...take a look at the improvements for the 6100 as additional
  1707. optimizations are added.  Notice that essentially there aren't any
  1708. improvements.
  1709.  
  1710. What is being compared is optimized code (I suspect, but don't have access
  1711. to the compilers on the other systems compared) versus essentially
  1712. unoptimized code.  With the added complication that different hardware is
  1713. running the optimized code.
  1714.  
  1715.  
  1716. > >So what does this mean???
  1717.  
  1718. It means that CodeWarrior isn't finished.  There are easier ways to learn
  1719. this astounding fact, such as by looking at the version number.
  1720.  
  1721. ****Someone who has the means:
  1722.     Could we run the code in question through the xlc compiler, move it to
  1723. the Mac, and time it?
  1724.  
  1725.     [Given the code, I could now do that for the MPW compiler, which is
  1726. said to lie between xlc and CodeWarrior in current quality...closer to the
  1727. former.]
  1728. -- 
  1729. John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
  1730.    jwbaxter@pt.olympus.net
  1731.  
  1732. +++++++++++++++++++++++++++
  1733.  
  1734. >From John Brewer <jbrewer@wri.com>
  1735. Date: Tue, 3 May 1994 03:11:15 GMT
  1736. Organization: Wolfram Research, Inc.
  1737.  
  1738. In article <bcorrie.767393999@tara> Brian  Corrie, bcorrie@csr.UVic.CA writes:
  1739. >The code performs typical 3D shading calculations (as would be found in a 3D
  1740. >renderer such as a ray tracer or scan-line renderer) a whole bunch of times
  1741. >in a tight loop. Timings were done on a IBM RS6000 (POWERStation 375) a
  1742. >SPARC 10, a SPARC 2 GX, a PowerMac 7100 (PowerPC @ 66Mhz), a PowerMac 6100 
  1743. >(PowerPC @ 60Mhz), a Quadra 840 (68040 @ 40MHz), and a NeXTstation
  1744. >(68040 @ ??Mhz).
  1745.  
  1746. It'd be interresting to try using xlc to generate the PowerMac code.
  1747. It seems to be the best at optimization, although it can easily take up to
  1748. 100 Mb of swap space to compile a large program.
  1749.  
  1750. John Brewer
  1751. Wolfram Research, Inc.
  1752. (but speaking for myself)
  1753.  
  1754. +++++++++++++++++++++++++++
  1755.  
  1756. >From uzun@crash.cts.com (Roger Uzun)
  1757. Date: Tue, 3 May 1994 17:03:00 GMT
  1758. Organization: CTS Network Services (CTSNET/crash), San Diego, CA
  1759.  
  1760. I have this 3D shading code, the tight loop benchmark that
  1761. was circulating around here, but I do not know how
  1762. many loops were performed to get the results that
  1763. were posted was it 1,000,000?
  1764. The default is 1000 and this executes in less than a second
  1765. on all machines around here (040, pentiums, no macs).
  1766. How many iterations were used in the running of this benchmark?
  1767. Also could someone repost any results people came up with.
  1768.  
  1769. -Roger
  1770. - ------------------------------------------------------------
  1771. bix: ruzun
  1772. NET: uzun@crash.cts.com
  1773.  
  1774. +++++++++++++++++++++++++++
  1775.  
  1776. >From bcorrie@csr.UVic.CA (Brian  Corrie)
  1777. Date: 3 May 94 23:47:51 GMT
  1778. Organization: University of Victoria
  1779.  
  1780. uzun@crash.cts.com (Roger Uzun) writes:
  1781. >I have this 3D shading code, the tight loop benchmark that
  1782. >was circulating around here, but I do not know how
  1783. >many loops were performed to get the results that
  1784. >were posted was it 1,000,000?
  1785. >The default is 1000 and this executes in less than a second
  1786. >on all machines around here (040, pentiums, no macs).
  1787. >How many iterations were used in the running of this benchmark?
  1788. >Also could someone repost any results people came up with.
  1789.  
  1790. Oppps, Sorry about that. Yes, 1,000,000 is the correct magic
  1791. number to produce the same results that I got. Please post any
  1792. results that you get....
  1793.  
  1794. Cheers,
  1795.  
  1796.     Brian
  1797.  
  1798. --
  1799.                   Brian Corrie (bcorrie@csr.uvic.ca)
  1800. Under the most rigorously controlled conditions of pressure, temperature,
  1801. volume, humidity and other variables, the organism will do as it damn well
  1802. pleases. Sounds like some of the code I have written......  8-)
  1803.  
  1804. +++++++++++++++++++++++++++
  1805.  
  1806. >From oliver@psy.fsu.edu (Bill Oliver)
  1807. Date: 4 May 1994 14:14:33 GMT
  1808. Organization: FSU Psych Dept
  1809.  
  1810. In article <bcorrie.768008871@tara>
  1811. bcorrie@csr.UVic.CA (Brian  Corrie) writes:
  1812.  
  1813. > uzun@crash.cts.com (Roger Uzun) writes:
  1814. > >I have this 3D shading code, the tight loop benchmark that
  1815. > >was circulating around here, but I do not know how
  1816. > >many loops were performed to get the results that
  1817. > >were posted was it 1,000,000?
  1818. > >The default is 1000 and this executes in less than a second
  1819. > >on all machines around here (040, pentiums, no macs).
  1820. > >How many iterations were used in the running of this benchmark?
  1821. > >Also could someone repost any results people came up with.
  1822. > Oppps, Sorry about that. Yes, 1,000,000 is the correct magic
  1823. > number to produce the same results that I got. Please post any
  1824. > results that you get....
  1825. > Cheers,
  1826. >         Brian
  1827.  
  1828.  
  1829.  
  1830. Your code is taking approximately 35 seconds to run on my Centris
  1831. 660AV. The compiler I'm using is Metrowerks CW C (68020&6881 Codegen, 4
  1832. Byte Ints, Peephole & CSE optimizers). I'm quite happy with this result
  1833. given the other times that were posted (I'm reposting those below). I
  1834. think I'll wait on the PowerMac :-)
  1835.  
  1836. -Bill-
  1837.  
  1838. >>Machine                 Time (seconds)    Compiler       Optimization?
  1839. >>=====================================================================
  1840. >>RS6000                4.1             xlC             -O2
  1841. >>RS6000                4.1             xlC             -O
  1842. >>RS6000                4.9             xlC             none
  1843. >>RS6000                5.1             xlC             -g
  1844. >>
  1845. >>SPARC 10             4.7             acc             -O2 libm.il
  1846. >>SPARC 10             4.9             acc             -O2
  1847. >>SPARC 10             4.9             acc             -O
  1848. >>SPARC 10             5.6             acc             none
  1849. >>SPARC 10             5.7             acc             -g
  1850. >>
  1851. >>SPARC 2GX            11.6            acc             -O2
  1852. >>SPARC 2GX            13.9            acc             none
  1853. >>
  1854. >>PowerMac 7100                12              CodeWarrior     some??
  1855. >>PowerMac 6100                16.52           CodeWarrior     Peep
  1856. >>PowerMac 6100                16.56           CodeWarrior     Peep + Glob
  1857. >>PowerMac 6100                16.43           CodeWarrior     Peep + Glob 
  1858. + IS
  1859. >>PowerMac 6100                16.15           CodeWarrior     Peep + Glob 
  1860. + IS
  1861. >>                                                      No extensions
  1862. >>
  1863. >>NeXTstation          32.9            gcc             -O2
  1864. >>
  1865. >>Quadra 840           34              SymantecAll
  1866.  
  1867. +++++++++++++++++++++++++++
  1868.  
  1869. >From Dave Falkenburg <falken@apple.com>
  1870. Date: Fri, 29 Apr 1994 08:00:16 GMT
  1871. Organization: Apple Computer, Inc.
  1872.  
  1873. In article <TMCGRATH.94Apr27162028@netcom10.netcom.com> Timothy McGrath,
  1874. tmcgrath@netcom10.netcom.com writes:
  1875. >I compiled POV-Ray, a popular freeware raytracer, on a 25Mhz 68040 unix
  1876. box
  1877. >and compared POV-Ray's performance to my own 33Mhz 68040-based Mac
  1878. >(with cache; Symantec C 6.0). The results for such a floating-point
  1879. >intensive application: the Unix box won by being 30% faster!! (Worse
  1880. still,
  1881. >yer bog $1500 486-66 runs the same app about 50% faster than the Unix
  1882. box).
  1883.  
  1884. Are you running the version that calls SetCPixel for every pixel to be
  1885. rendered?
  1886. My brother recompiled POV a couple of months ago and got barn-burning
  1887. performance out of it.
  1888.  
  1889. The Mac-specific stuff in the version you have might be a complete dog.
  1890.  
  1891. >I don't know if the problem is poor compiler optimization, poor runtime
  1892. >libraries, poor performance out of system software, or bottlenecks in
  1893. the Mac
  1894. >hardware. I'm about the biggest Mac fan there is, and I'm really unhappy
  1895. >that my favorite computer is such a performance dog.
  1896.  
  1897. Remember that CW isn't final yet AND this version will not be as good as
  1898. xlc on AIX, or PPCC in the PowerMac SDK.
  1899.  
  1900. One big hog is mathlib--> the AIX libm.a is MUCH faster than one in ROM
  1901. Apple is shipping today-- it's hand tuned code for calculating sin, cos,
  1902. etc.
  1903.  
  1904.  
  1905. If I were a developer, I'd scream at the top of my lungs at the WWDC
  1906. about this...
  1907.  
  1908.  
  1909. -Dave Falkenburg
  1910. -Not speaking for "Apple Computer, Inc." in this posting
  1911.  
  1912. ---------------------------
  1913.  
  1914. >From rcohen@ssl.umd.edu (Rob Cohen)
  1915. Subject: Saving the floating Point Registers
  1916. Date: 26 Apr 1994 20:43:17 GMT
  1917. Organization: Space Systems Laboratory, University of Maryland
  1918.  
  1919. I've written an interrupt service routine that when called does some
  1920. floating point math.  There is also a lot of floating point math that
  1921. goes on in the rest of the code.  Unfortunately, my code crashes when
  1922. I'm running the ISR in places that do math.  I think the problem is
  1923. that I'm not preserving the values in the floating point registers.  I
  1924. think I want to push them on the stack when I enter the ISR, do what I
  1925. have to do and then pop them off.  My question then becomes how do you
  1926. do this.  I know the locations of the floating point register,
  1927. FP0...FP7, but what does the assembler look like to do this.
  1928.  
  1929. Thanks
  1930.  
  1931. - -----------------------------------------------------------------
  1932. Rob Cohen              rcohen@ssl.umd.edu
  1933.  
  1934. The views expressed here are my own Blah, blah, blah, blah (The
  1935. standard disclaimer)
  1936.  
  1937. +++++++++++++++++++++++++++
  1938.  
  1939. >From Ron_Hunsinger@bmug.org (Ron Hunsinger)
  1940. Date: Sun,  1 May 94 23:38:47 PST
  1941. Organization: Berkeley Macintosh Users Group
  1942.  
  1943. rcohen@ssl.umd.edu (Rob Cohen) writes:
  1944.  
  1945. >I've written an interrupt service routine that when called does some
  1946. >floating point math.  There is also a lot of floating point math that
  1947. >goes on in the rest of the code.  Unfortunately, my code crashes when
  1948. >I'm running the ISR in places that do math.  I think the problem is
  1949. >that I'm not preserving the values in the floating point registers.  I
  1950. >think I want to push them on the stack when I enter the ISR, do what I
  1951. >have to do and then pop them off.  My question then becomes how do you
  1952. >do this.  I know the locations of the floating point register,
  1953. >FP0...FP7, but what does the assembler look like to do this.
  1954.  
  1955. It's not just the registers that have to be saved.  You have to save
  1956. the state of the FPU also, since you could have interrupted it in the
  1957. middle of an operation.  In general, you have to:
  1958.  
  1959.     FSAVE    <ea>                   ; save the non-visible state
  1960.     FMOVEM.L FPCR/FPSR/FPIAR, <ea>  ; save the control registers
  1961.     FMOVEM.X FP0-FP7, <ea>          ; save the data registers
  1962.  
  1963.     ; establish the environment you want to run in
  1964.     ;          (rounding rules, traps, etc) because the task you
  1965.     ;          interrupted may have changed them.  A quick way to
  1966.     ;          reset the fpu is to do an FRESTORE from a longword
  1967.     ;          containing $00000000, but this clears ALL the registers
  1968.     ;          so you can't have skimped on any of the above register-
  1969.     ;          saving.
  1970.  
  1971.     ; do your work
  1972.  
  1973.     FMOVEM.X <ea>, FP0-FP7          ; restore the data registers
  1974.     FMOVEM.L <ea>, FPCR/FPSR/FPIAR  ; restore the control registers
  1975.     FRESTORE <ea>                   ; restore the non-visible state
  1976.  
  1977. All of this saving and restoring is not guaranteed to be cheap, which 
  1978. is why it wasn't done automatically for you.
  1979.  
  1980. -Ron Hunsinger
  1981.  
  1982. ---------------------------
  1983.  
  1984. >From Daniel Jibouleau <jiboule@hermes.ulaval.ca>
  1985. Subject: The NewWindow case
  1986. Date: Thu, 28 Apr 1994 23:19:08 GMT
  1987. Organization: Université Laval
  1988.  
  1989. For a long time now, i am still asking myself whether it is better to
  1990. call NewWindow (or GetNewWindow) with a storage or to let it allocate
  1991. it's storage itself.  Note that both ways may be correct.  Consider the
  1992. following example:
  1993.  
  1994. NewWindow with a storage:
  1995.  
  1996. {
  1997.     WindowPtr theWindow;
  1998.     WindowRecord windStorage;
  1999.     
  2000.     /* Use a pointer to our storage to store the window associated
  2001. information.  It will be stored on the stack, thus reducing heap
  2002. fragmentation. */
  2003.     theWindow = GetNewWindow (&windStorage, fooWindID, (WindowPtr) -1L);
  2004. }
  2005.  
  2006. NewWindow without storage:
  2007.  
  2008. {
  2009.     WindowPtr theWindow;
  2010.     
  2011.     /* Let the Window Manager allocate the storage for the window itself.
  2012.  It will be placed on the heap, thus increasing chances of heap
  2013. fragmentation.  The Window Manager may be doing this in a better way,
  2014. tough. */
  2015.     theWindow = GetNewWindow (nil, fooWindID, (WindowPtr) -1L);
  2016. }
  2017.  
  2018.  
  2019. Daniel Jibouleau
  2020. jiboule@hermes.ulaval.ca
  2021.  
  2022. +++++++++++++++++++++++++++
  2023.  
  2024. >From rmah@panix.com (Robert S. Mah)
  2025. Date: Fri, 29 Apr 1994 10:16:54 -0500
  2026. Organization: One Step Beyond
  2027.  
  2028. Daniel Jibouleau <jiboule@hermes.ulaval.ca> wrote:
  2029.  
  2030. > For a long time now, i am still asking myself whether it is better to
  2031. > call NewWindow (or GetNewWindow) with a storage or to let it allocate
  2032. > it's storage itself.  Note that both ways may be correct.  Consider the
  2033. > following example:
  2034. > NewWindow with a storage:
  2035. > {
  2036. >     WindowPtr theWindow;
  2037. >     WindowRecord windStorage;
  2038. >     
  2039. >     /* Use a pointer to our storage to store the window associated
  2040. > information.  It will be stored on the stack, thus reducing heap
  2041. > fragmentation. */
  2042. >     theWindow = GetNewWindow (&windStorage, fooWindID, (WindowPtr) -1L);
  2043. > }
  2044. > NewWindow without storage:
  2045. > {
  2046. >     WindowPtr theWindow;
  2047. >     
  2048. >     /* Let the Window Manager allocate the storage for the window itself.
  2049. >  It will be placed on the heap, thus increasing chances of heap
  2050. > fragmentation.  The Window Manager may be doing this in a better way,
  2051. > tough. */
  2052. >     theWindow = GetNewWindow (nil, fooWindID, (WindowPtr) -1L);
  2053. > }
  2054.  
  2055. The first example is very, very dangerous.  Since the storage is a local
  2056. variable, and allocated on the stack, it goes away after the function
  2057. is exited.  This is fine if that function is main(), but not the other
  2058. way around.  Better to use a global (or static) if you care about heap
  2059. fragging.
  2060.  
  2061. My rule of thumb is to use static/global (stack based) allocation for
  2062. window storage only if the app only uses a small, fairly constant set 
  2063. of windows.  For apps with user-created documents, static allocation
  2064. is not such a good thing because it would limit the # of docs the user
  2065. could open.
  2066.  
  2067. Cheers,
  2068. Rob
  2069. ___________________________________________________________________________
  2070. Robert S. Mah  -=-  One Step Beyond  -=-  212-947-6507  -=-  rmah@panix.com
  2071.  
  2072. +++++++++++++++++++++++++++
  2073.  
  2074. >From dean@genmagic.com (Dean Yu)
  2075. Date: 29 Apr 1994 17:57:56 GMT
  2076. Organization: General Magic, Inc.
  2077.  
  2078. In article <Cozsrx.6Kp@athena.ulaval.ca>, Daniel Jibouleau
  2079. <jiboule@hermes.ulaval.ca> wrote:
  2080. > For a long time now, i am still asking myself whether it is better to
  2081. > call NewWindow (or GetNewWindow) with a storage or to let it allocate
  2082. > it's storage itself.  Note that both ways may be correct.  Consider the
  2083. > following example:
  2084.  
  2085.   Although allocating the storage space for the window record yourself
  2086. might help your memory management now, it might be a hindrance in the
  2087. future. If Apple ever goes to a protected memory model, it would almost
  2088. definitely be better if the toolbox would be able to allocate its data
  2089. structures in another address space and pass you a reference to that data
  2090. structure. If everyone specified nil as the wStorage parameter now, it
  2091. would be much much simpler for a future Window Manager to change while
  2092. still maintaining API compatibility. But because storage can be allocated
  2093. by the application, it makes moving forward while still maintaining
  2094. compatibility much more difficult.
  2095.   I've gone on tirades about this topic before; it was something I really
  2096. wanted to do at Apple, but never had the time for. :/
  2097.  
  2098. -- Dean Yu
  2099.    Negative Ethnic Role Model
  2100.    General Magic, Inc.
  2101.  
  2102. ---------------------------
  2103.  
  2104. >From ereidell@media.mit.edu (Evan A. Reidell)
  2105. Subject: Truetype font format specification: No longer available from Apple ?!
  2106. Date: Mon, 25 Apr 1994 19:57:29 GMT
  2107. Organization: MIT Media Laboratory
  2108.  
  2109. I have been having a hell of a time trying to find 
  2110. the Apple TrueType font format specification.
  2111.  
  2112. Luckily, this is _theoretically_ available
  2113. as "Apple Finished Goods" product number:
  2114. M0825 LL/A ``TrueType font format specification''
  2115.  
  2116. Unluckily, no one at ALL seems to know anything about it.
  2117.  
  2118. I've been bounced around between Catalog Sales, Apple Authorized Dealers,
  2119. AP.D.A, Apple Customer Assistance, and Apple R&D groups so many times
  2120. that I'm beginning to wonder if the TrueType font format even exists.
  2121.  
  2122. Is it worth the grief??  Or is Adobe PostScript the way to go,
  2123. no matter how Apple and Microsoft would like to play their games?
  2124.  
  2125. Can anyone out there help me get my hands on this "document" ?
  2126.  
  2127. -- evan reidell
  2128.  
  2129. +++++++++++++++++++++++++++
  2130.  
  2131. >From s66039@cc.ntnu.edu.tw (Riboflavin)
  2132. Date: Tue, 26 Apr 1994 09:54:40 GMT
  2133. Organization: NTNU, Taiwan, R.O.C.
  2134.  
  2135. Evan A. Reidell (ereidell@media.mit.edu) wrote:
  2136. : I have been having a hell of a time trying to find 
  2137. : the Apple TrueType font format specification.
  2138. : Unluckily, no one at ALL seems to know anything about it.
  2139. : I've been bounced around between Catalog Sales, Apple Authorized Dealers,
  2140. : AP.D.A, Apple Customer Assistance, and Apple R&D groups so many times
  2141. : that I'm beginning to wonder if the TrueType font format even exists.
  2142. : Is it worth the grief??  Or is Adobe PostScript the way to go,
  2143. : no matter how Apple and Microsoft would like to play their games?
  2144.  
  2145. I don't know, I had an heck of a time getting a particular document from
  2146. Adobe a while back, but they finally came through. As for the TrueType spec.,
  2147. forget Apple. Instead, ftp to ftp.microsoft.com and look for it - it's there!
  2148. Only catch is it comes either as a Windows help file, or as a PC Word 2.0 
  2149. file, the latter of which you should be able to load into your Mac version
  2150. of Word.
  2151.  
  2152. -Steven Fox-
  2153.  
  2154.  
  2155. +++++++++++++++++++++++++++
  2156.  
  2157. >From tkr@puffball.demon.co.uk (Tim Rylance)
  2158. Date: Tue, 26 Apr 1994 11:45:10 +0000
  2159. Organization: Tim Rylance, Bath, UK
  2160.  
  2161. s66039@cc.ntnu.edu.tw (Riboflavin) writes:
  2162.  
  2163. >I don't know, I had an heck of a time getting a particular document from
  2164. >Adobe a while back, but they finally came through. As for the TrueType spec.,
  2165. >forget Apple. Instead, ftp to ftp.microsoft.com and look for it - it's there!
  2166. >Only catch is it comes either as a Windows help file, or as a PC Word 2.0 
  2167. >file, the latter of which you should be able to load into your Mac version
  2168. >of Word.
  2169.  
  2170. There's a Postscript version at
  2171.  
  2172.   ftp.icce.rug.nl:pub/erikjan/truetype/ttspec/*.ps
  2173.  
  2174. --
  2175. Tim Rylance <tkr@puffball.demon.co.uk>
  2176.  
  2177. +++++++++++++++++++++++++++
  2178.  
  2179. >From vens007@telecom.ptt.nl (Erik-Jan Vens,HD,)
  2180. Date: 26 Apr 1994 11:53:04 +0200
  2181. Organization: PTT Telecom B.V. The Netherlands
  2182.  
  2183. dixit ereidell@media.mit.edu (Evan A. Reidell) in <1994Apr25.195729.2855@news.media.mit.edu>:
  2184. >I have been having a hell of a time trying to find 
  2185. >the Apple TrueType font format specification.
  2186. >
  2187. >Luckily, this is _theoretically_ available
  2188. >as "Apple Finished Goods" product number:
  2189. >M0825 LL/A ``TrueType font format specification''
  2190.  
  2191. Supposedly the TrueType format should be the same for DOS and Apple.
  2192. Maybe you should try ftp.icce.rug.nl in pub/erikjan/truetype/ttspec. I
  2193. have converted the MS version to Postscript.
  2194.  
  2195. EJee
  2196.  
  2197. -- 
  2198. - -----------------------------------------------------------------------------
  2199. Erik-Jan Vens             | Telephone: +31 50 855994
  2200. PTT Telecom BV            | Telefax  : +31 50 855777
  2201. I&AT                | E-mail   : vens007@telecom.ptt.nl
  2202. P.O. Box 188            | DISCLAIMER: This statement is not an official
  2203. NL-9700 AD Groningen        | statement from, nor does it represent an
  2204. The Netherlands            | official position of, PTT Telecom B.V.
  2205. - -----------------------------------------------------------------------------
  2206.  
  2207. +++++++++++++++++++++++++++
  2208.  
  2209. >From pan@vaxc.cc.monash.edu.au (Pan Thongvilu)
  2210. Date: 27 Apr 1994 02:34:50 GMT
  2211. Organization: Monash University
  2212.  
  2213. In article <1994Apr26.095440.19400@cc.ntnu.edu.tw>, s66039@cc.ntnu.edu.tw (Riboflavin) writes:
  2214. |> Evan A. Reidell (ereidell@media.mit.edu) wrote:
  2215. |> : I have been having a hell of a time trying to find 
  2216. |> : the Apple TrueType font format specification.
  2217. |> : Unluckily, no one at ALL seems to know anything about it.
  2218. |> : I've been bounced around between Catalog Sales, Apple Authorized Dealers,
  2219. |> : AP.D.A, Apple Customer Assistance, and Apple R&D groups so many times
  2220. |> : that I'm beginning to wonder if the TrueType font format even exists.
  2221. |> : Is it worth the grief??  Or is Adobe PostScript the way to go,
  2222. |> : no matter how Apple and Microsoft would like to play their games?
  2223. |> 
  2224. |> I don't know, I had an heck of a time getting a particular document from
  2225. |> Adobe a while back, but they finally came through. As for the TrueType spec.,
  2226. |> forget Apple. Instead, ftp to ftp.microsoft.com and look for it - it's there!
  2227. |> Only catch is it comes either as a Windows help file, or as a PC Word 2.0 
  2228. |> file, the latter of which you should be able to load into your Mac version
  2229. |> of Word.
  2230. |> 
  2231. |> -Steven Fox-
  2232. |> 
  2233.     Hi,
  2234.  
  2235.     I went to ftp.microsoft.com a couple of times. I looked and looked
  2236.     but could not find it. 
  2237.  
  2238.     Can someone tell us where to find it on the tree and what it is 
  2239.     called so I can do an 'archie -c' on it.
  2240.  
  2241.     Thanks,
  2242.     Pan.
  2243.  
  2244. +++++++++++++++++++++++++++
  2245.  
  2246. >From dmunsil@netcom.com (Don Munsil)
  2247. Date: Wed, 27 Apr 1994 16:48:08 GMT
  2248. Organization: The Munsil/Stone Organization
  2249.  
  2250. Pan Thongvilu (pan@vaxc.cc.monash.edu.au) wrote:
  2251. : In article <1994Apr26.095440.19400@cc.ntnu.edu.tw>, s66039@cc.ntnu.edu.tw (Riboflavin) writes:
  2252. : |> Evan A. Reidell (ereidell@media.mit.edu) wrote:
  2253. : |> : I have been having a hell of a time trying to find 
  2254. : |> : the Apple TrueType font format specification.
  2255.  
  2256. :     I went to ftp.microsoft.com a couple of times. I looked and looked
  2257. :     but could not find it. 
  2258.  
  2259. It's in about the most un-intuitive place imaginable -- I believe it's 
  2260.  
  2261. /developer/drg/Truetype-Info
  2262.  
  2263. There are a lot of documents in there. Beware! The Word for Windows 
  2264. document is not as up-to-date as the most recent printed version. The 
  2265. WinHelp file appears to be about the same as the printed version. There 
  2266. are problems and errors in the 1.00 version, so be careful.
  2267.  
  2268. --Don
  2269. -- 
  2270. - ----------------------------------------------------
  2271. Don Munsil          | I respect faith, but doubt is
  2272. dmunsil@netcom.com  | what gets you an education.
  2273. don@elseware.com    |                 -- Wilson Mizner
  2274.  
  2275. +++++++++++++++++++++++++++
  2276.  
  2277. >From zune@lysator.liu.se (Andreas Magnusson)
  2278. Date: 29 Apr 1994 10:42:13 GMT
  2279. Organization: (none)
  2280.  
  2281. dmunsil@netcom.com (Don Munsil) writes:
  2282.  
  2283. >Pan Thongvilu (pan@vaxc.cc.monash.edu.au) wrote:
  2284.  
  2285. >It's in about the most un-intuitive place imaginable -- I believe it's 
  2286.  
  2287. >/developer/drg/Truetype-Info
  2288.  
  2289. >There are a lot of documents in there. Beware! The Word for Windows 
  2290. >document is not as up-to-date as the most recent printed version. The 
  2291. >WinHelp file appears to be about the same as the printed version. There 
  2292. >are problems and errors in the 1.00 version, so be careful.
  2293.  
  2294. >--Don
  2295. >-- 
  2296. >------------------------------------------------------
  2297. >Don Munsil          | I respect faith, but doubt is
  2298. >dmunsil@netcom.com  | what gets you an education.
  2299. >don@elseware.com    |                 -- Wilson Mizner
  2300.  
  2301. While we're at it, can somebody tell me if the Apple docs are better, or 
  2302. at least more readable than the Microsoft docs.
  2303. It's a personal taste, but I can't for my life understand the MS-docs. 
  2304. All there are is a listing of all the instructions, and how they supposedly
  2305. work, but no examples or tips or tricks. It's a shame since the Adobe
  2306. docs for Type 1 (which isn't as complex, I know) is full of examples that
  2307. enables me to fully decode, understand and even hand code changes in a font.
  2308. Especially since they say that it's meant to put the intelligence in the
  2309. font instead of in the rasterizer.
  2310.  
  2311. Is there any examples at all available for TrueType? 
  2312.  
  2313. Bye
  2314. /Andreas
  2315. --
  2316. | Andreas Magnusson                  || Vet ni varf|r datavetare {r s}      |
  2317. | Linkoping Institute of Technology  || smarta? Jo, de LISTAR ut allt!      |
  2318. | c89andma@odalix.ida.liu.se         ||      Karin Willborg, C89 LiTH       |
  2319. | zune@nanny.lysator.liu.se          ||(This is in Swedish, it's a bad joke)|
  2320.  
  2321. ---------------------------
  2322.  
  2323. End of C.S.M.P. Digest
  2324. **********************
  2325.  
  2326.  
  2327.  
  2328.